Using End-to-end Statistics to Distinguish Congestion and Corruption Losses: a Negative Result

On wireless links, the rate of corruption losses can be signiicant, leading to poor TCP performance. The performance gets worse when these losses are mistaken for congestion losses, unduly triggering the TCP congestion control algorithms. To avoid this, techniques to distinguish between corruption and congestion losses without any explicit information from the network (routers or switches) are of interest. In the past, several proposals require TCP sender to reduce its window size when congestion is detected. These schemes use heuristics to detect congestion by using some simple statistics on round-trip delays and/or throughput. If the heuristics developed in the past are good (i.e., accurate much of the time), then one possible mechanism for distinguishing between errors and congestion are as follows: (a) Use a good heuristic that asks TCP sender to reduce window size when congestion is 1 detected. (b) If a packet loss occurs, see what the heuristic said just before the packet was sent. (c) If the heuristic had said reduce window (because congestion was detected), assume that the packet loss is due to congestion, otherwise assume that packet loss is due to transmission error. Take appropriate action depending on the nature of packet loss. The above scheme will work well, if the heuristic is very accurate. Unfortunately, our preliminary measurements suggest that three such heuristics proposed previously do not perform well in practice. The reason, essentially, is that to a well-behaved TCP connection, packet losses seem to appear almost random, without much correlation to the window size or round-trip delays. This is true (and intuitive) when an individual connection represents only a small fraction of load at a router on the path.